REMARKS 

Reconsideration of this application as amended is respectfully requested. 

The enclosed is responsive to the Examiner's Office Action mailed on September 
21 , 2007. At the time the Examiner mailed the Office Action, claims 1-17 were pending. 
By way of the present response applicants have: 1) amended claims 1, 5, 9, and 13; 2) 
added no claims; and 3) canceled no claims. As such, claims 1-17 are now pending. 

Applicants reserve all rights under the Doctrine of Equivalents. 



Claim Rejections - 35 U.S.C. § 102 
The Examiner rejected claims 1-17 under 35 U.S.C. § 102(a) as being 
anticipated by the admitted prior art in the background of the application (hereinafter 
"APA'). 

In reference to claim 1 , the Examiner stated that: 

APA discloses "a method for upgrading a database" [i.e., database 
upgrading, previous versions; page 1, lines 18-19], comprising: 

"updating a message from a first version to an upgraded version by 
chaining through intermediate versions" [i.e., version database is a 
specific schema and the specific data in the structures, databases are 
embodied in a series of versions, each with a changed schema and new 
data elements. A new version of the database is generated from an old 
one by upgrading its schema and mapping its data to the new schema. 
Database software generally support upgrading from any of several 
previous versions; see page 1 lines 13-19], 

"wherein updating comprises: receiving an update message having 
a first version format; and repeatedly generating a revised update 
message having a next most recent version format based on the update 
message until a final update message having an upgraded version format 
is generated" [i.e., in a redundancy environment, upgrading is sometimes 
performed by upgrading a mirror image database to the new version and 
then at the appropriate time switching to use the mirror image as the 
primary database, process, upgrading is performed by receiving database 
update messages from a previous version and mapping them into the 
schema of the new version, an empty database structure conforming to 
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the schema of the new version is created to accept these mappings; see 
page 2, lines 1-8]. 

(Office action dated September 21, 2007 pages 2-3). 

It is respectfully submitted that the APA does not disclose all of the limitations of 

amended claim 1 , which reads: 

A method for upgrading the schema of a database, comprising: 
updating a message from a first version to an upgraded version by 
chaining through intermediate versions, wherein updating 
comprises: 

receiving an update message having a first version format; and 
repeatedly generating a revised update message having a next 
most recent version format based on the update message until 
a final update message having an upgraded version format is 
generated. 

(Amended claim 1) (emphasis added). 

The APA does not disclose updating by chaining through intermediate versions, 

nor does it disclose repeatedly generating a revised update message having a next 

most recent version format based on the update message until a final update message 

having an upgraded version format is generated. In contrast, the APA states that: 

A new release of database software might support the upgrading of 
databases from up to three previous generations. In existing systems, 
each new software release provides separate modules for each prior 
release from which an upgrade is possible. Upgrade code must be 
developed to map each of these three old releases into the current 
release, with all of the upgrade code for each new version written 
anew in each release (using older release code as a model). Thus, if the 
latest database software is at release 4, and assuming that releases have 
been numbered only at full numeral versions (e.g., release 1 , release 2, 
and release 3), then the upgrade code for release 4 must contain code 
to convert the databases to release 4 directly from release 1, release 
2, or release 3. 

The current upgrade system requires the duplication of code for 
mapping and writing databases for each prior supported version. 

(Background of present application, pages 2-3). 
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The APA discloses a method of updating directly from the existing version to the 
upgraded version without chaining through intermediate versions and repeatedly 
generating a revised update message having a next most recent version format based 
on the update message until a final update message having an upgraded version format 
is generated. 

Given that claims 2-4 are dependent claims with respect to claim 1 , either directly 
or indirectly, and add additional limitations, applicants submit that claims 2-4 are not 
anticipated by the APA under 35 U.S.C. § 102(a). 

Given that claims 5-8, 9-12, and 13-17 were rejected based upon the same art 
and rationale as claims 1-4 and claims 5-8, 9-12, and 13-17 have similar limitations as 
claims 1-4 that are not disclosed in the APA, applicants submit that claims 5-8, 9-12, 
and 13-17 are not anticipated by the APA under 35 U.S.C. § 102(a) for the same 
reasons as discussed above. 

Applicants, accordingly, respectfully submit that the rejection of claims 1-17 
under 35 U.S.C. § 102(a) as being anticipated by the APA has been overcome. 

The Examiner also rejected claims 1-17 under 35 U.S.C. § 102(a) as being 
anticipated by Hug, et al., U.S. Patent No. 5,806,078 (hereinafter "Hug"). 

In reference to claim 1 , the Examiner stated that: 

Hug discloses "a method for upgrading a database" [see col. 79, 
lines 5-23], comprising: 

"updating a message from a first version to an upgraded version by 
chaining through intermediate versions" [i.e., version data file 40 and the 
difference data file 42 to reflect the changes in the subsequent version; 
col. 5 lines 38-41], 

"wherein updating comprises: receiving an update message having 
a first version format" [i.e., regenerating version (20); see col. 5, lines 38- 
46]; "and repeatedly [i.e., iteratively repeat; see col. 5, lines 58-60] 
generating a revised update message having a next most recent version 
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format based on the update message until a final update message having 
an upgraded version format is generated" [see col. 5, lines 48-56]. 

(Office action dated September 21 , 2007 page 4). 

It is respectfully submitted that Hug does not disclose all of the limitations of 

amended claim 1, which reads: 

A method for upgrading the schema of a database, comprising: 
updating a message from a first version to an upgraded 
version by chaining through intermediate versions, wherein 
updating comprises: 

receiving an update message having a first version format; and 
repeatedly generating a revised update message having a next 
most recent version format based on the update message until a 
final update message having an upgraded version format is 
generated. 

(Amended claim 1, emphasis added). 

Hug discloses a "version management system for storing and retrieving changes 
to spreadsheet and word processor documents" which permits "a user to access a 
plurality of versions" of those documents. (Hug, Abstract). "An original version of each 
document and all alternative versions are stored in a delta format, i.e., storing only the 
differences from a prior document version, in a common difference data file and version 
data file." (Hug, Abstract). The difference data file 42 contains sets of data records 
reflecting the delta-formatted differences from each prior version of a document, e.g., 
the changed data and the cell location in a spreadsheet." (Hug, col. 6, lines 7-11). 
"\T\he version data file 40 contains a set of pointers 54 for each stored document 
version that point to a set of data records in the difference file 42 that are used to 
regenerate each document version." (Hug, col. 6, lines 22-27). 

Hug does not disclose a "upgrading the schema of a database." In contrast, Hug 
compares the differences between data edits made by a user to a document and stores 



Inventors): Jerome A. Mouton, Jr. et al. 
Application No.: 09/295,690 



-9- 



Examiner: Jean B. Fleurantin 
Art Unit: 2162 



those differences in a set of files. The Examiner made reference to Hug, col. 79, lines 
5-23 (Office action dated September 21 , 2007 page 4). However, Hug does not contain 
a column 79. Applicants assume that the Examiner was referring to Nakagawa (see 
Office action dated September 21 , 2007 page 2). The basis for the Examiner's rejection 
was 35 U.S.C. § 102(a), not 35 U.S.C. § 103. There was no discussion of a 
combination of the two patents and no articulation of a motivation to combine the two 
patents. 

If the Examiner had based the rejection upon 35 U.S.C. § 103, applicants 
respectfully assert that one of ordinary skill in the art would not be motivated to combine 
the references and, even if combined, the combination would still lack the limitations of 
amended claim 1 . Nakagawa discloses a client program to detect software updates, 
download them from a server, and update the software "according to the update 
instruction information when it is received." (Nakagawa, Abstract). Nakagawa does not 
disclose a "upgrading the schema of a database." 

Finally, Hug does not disclose "updating a message from a first version to an 
upgraded version by chaining through intermediate versions ... receiving an update 
message having a first version format; and repeatedly generating a revised update 
message." In contrast, the contents of the version control files in Hug are the data 
edited by a user and pointers to the locations in the document of the data edited by a 
user. 

Given that claims 2-4 are dependent claims with respect to claim 1 , either directly 
or indirectly, and add additional limitations, applicants submit that claims 2-4 are not 
anticipated by the Hug under 35 U.S.C. § 102(a). 
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Given that claims 5-8, 9-12, and 13-17 were rejected based upon the same art 
and rationale as claims 1-4 and claims 5-8, 9-12, and 13-17 have similar limitations as 
claims 1-4 that are not disclosed in the Hug, applicants submit that claims 5-8, 9-12, 
and 1 3-1 7 are not anticipated by the Hug under 35 U.S.C. § 1 02(a) for the same 
reasons as discussed above. 

Applicants, accordingly, respectfully submit that the rejection of claims 1-17 
under 35 U.S.C. § 102(a) as being anticipated by the Hug has been oyefcor^e. 



Applicants respectfully submit that in view of the amendments and arguments set 
forth herein, the applicable rejections have been overcome. 

Pursuant to 37 C.F.R. 1 .136(a)(3), applicants hereby request and authorize the 
U.S. Patent and Trademark Office to (1 ) treat any concurrent or future reply that 
requires a petition for extension of time as incorporating a petition for extension of time 
for the appropriate length of time and (2) charge all required fees, including extension of 
time fees and fees under 37 C.F.R. 1.16 and 1.17, to Deposit Account No. 02-2666. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 





Lester J. Vincent 
Reg. No. 31,460 



1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(408) 720-8300 
Customer No.: 08791 
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